Looks good @m453h (haven't checked the code yet). A few quick thoughts (totally open for discussion)

1. Why not have Forms as a separate group (rather than settings) where we can have Login form, Registration form, etc.
2. Instead of Input Elements and Form Messages as separate groups, why not combine them into one group Fields? Then for each field, you'll have two entries: label and errorMessage e.g. email.label, and email.errorMessage. Additionally there can be a third entry helpMessage (or placeholder) if a field needs to be extra descriptive.

Of course, we may need a common place to put those common message that are the same across all forms, etc., but may be we don't need it now? If we do, then this can go into Settings.

• Why not have Forms as a separate group (rather than settings) where we can have Login form, Registration form, etc.
  Hmmm 🤔 I like the idea of splitting the forms... let me move the components as per this suggestion and group the inputs as well, I think it would greatly improve the user experience

• Why not have Forms as a separate group (rather than settings) where we can have Login form, Registration form, etc.

Hmmm 🤔 I like the idea of splitting the forms... let me move the components as per this suggestion and group the inputs as well, I think it would greatly improve the user experience

• Why not have Forms as a separate group (rather than settings) where we can have Login form, Registration form, etc.

Hmmm 🤔 I like the idea of splitting the forms... let me move the components as per this suggestion and group the inputs as well, I think it would greatly improve the user experience

@kilemensi, let me know if this arrangement for the login form makes more sense

👍🏽 ... Definitely on the right track @m453h .

Not sure about "dynamic" fields. Don't we need to match names to what APIs expect e.g. email field must be called email, etc. If content editor renames it to emailAddress, will the form still work?

Yes we need to match the names, I had conflicting thoughts about dynamic fields (I opted to use them since they reduce repetitions in the code) and had kept a validator to ensure all the expected names from the front-end are included, since I have a function that creates these fields, I can quickly repurpose it to have pre-defined fields and remove this validator

@kilemensi to add a bit of context, I am using TextField in the Login, PasswordReset and Registration Forms instead of E-mail because, within the CMS, we expect the user to set what would appear as labels, error messages and hints on the font-end forms thus the user would always need to enter free text, using the E-mail field wouldn't work in this scenario.

Cool, cool @m453h ... got you now. The forms here are just for collecting messages (error, hints, etc.)

Don't wait for me on this PR @m453h but did you fix the titles e.g. Form Messages to just messages, Buttons to Actions, etc.

Don't wait for me on this PR @m453h but did you fix the titles e.g. Form Messages to just messages, Buttons to Actions, etc.

Sure, just cross-checked, I had one commit I didn't push for the labels...I think everything else should be alright